Use master pages for shared layout
What you'll see
A developer — or an AI code-generation tool — builds several pages or per-schema display templates that all need the same surrounding layout: the same <head>, the same stylesheet and script links, the same header and footer. Instead of sharing one layout, each .hash file repeats the full HTML document from <!DOCTYPE html> down to </html>. Common shape:
<!-- article.hash -->
<!DOCTYPE html>
<html><head>
<link rel="stylesheet" href="/style.css">
</head><body>
<header>...same nav as everywhere...</header>
<main>#Body#</main>
<footer>...same footer...</footer>
</body></html>When the navigation changes, every one of these files must be edited by hand — and they drift out of sync the moment one is missed.
What's actually happening
Docly's MASTER directive lets one .hash file act as the shared layout (the master page) while other pages declare only the content that is unique to them. The child page names the master with a first-line directive and uses xdt:Transform attributes to merge its content into the master's placeholders — replacing, inserting before/after, or removing elements.
A master page holds the document skeleton (the <head>, the shared CSS/JS links, the header, the footer) exactly once. Every page that inherits from it stays small and focused on its own content. Shared styles and scripts declared in the master are automatically applied to every page that uses it, which is what keeps a multi-page site visually and behaviourally consistent.
The cost of not doing this is duplication: the same chrome copied into dozens of files. Any layout change then becomes a find-and-replace across the whole workspace, and the inevitable missed file produces a page that looks subtly wrong or links to a stale stylesheet. Master pages remove that whole class of maintenance bug.
What to do
Whenever two or more pages or display templates share layout, extract that layout into a master page and inherit from it.
1. Create the master page (e.g. #/master.hash) with the shared skeleton. Keep it in the developer-only #/ tree so non-developer users never see it.
<!DOCTYPE html>
<html lang="no">
<head>
<title>Default title</title>
<meta charset="UTF-8" />
<link rel="stylesheet" href="/style.css" />
</head>
<body>
<header id="Header">...shared nav...</header>
<main id="Content"></main>
<footer>...shared footer...</footer>
</body>
</html>2. Inherit from it in each child page. The first line declares the master; xdt:Transform attributes merge content in.
<!--#master file="#/master.hash" -->
<!DOCTYPE html>
<html>
<head>
<title xdt:Transform="Replace">Article title</title>
</head>
<body>
<main id="Content" xdt:Transform="Replace">#Body#</main>
</body>
</html>Do — one master, many thin pages. A nav change is a single edit in #/master.hash.
Don't — copy the full HTML document into every page. It duplicates the chrome, drifts out of sync, and turns every layout tweak into a multi-file edit.
For solutions where non-developer users administer content, keep the master (and partials like #/Header.hash / #/Footer.hash) under #/ so they stay out of the editing workspace.
See Using master page files, the Master directive reference, and the "Using master pages" section of Create display templates for your schemas for full details.